In article <3a8945a1@news.povray.org> , "Scott Hill" 
<sco### [at] ncgraphicsnet> wrote:

>     Why not ? The point of the STL is that it is generic, i.e. designed to
> work with _any_ data classes - you really have to work hard to make your
> classes incompatible with the STL, so, what's up with the C++ code in 3.5
> that makes it so ?

You missed the point.  It is not that we are not compatible with the STL
(I never said that, did I?), but that there is no compatible STL.  Most
platforms are far behind when it comes to an ISO C++ STL implementation.
It starts with different, non-standard include file names, add continues
with missing or different names for classes and methods, not to mention
bugs.  For example, using standard STL would make compiling with the
currently available gcc plus libraries impossible (we spend a few days
sorting out just iostreams).  Other problems include template support in
many compilers, and so on, and so on.  Besides, we would be using two
memory models, one based on malloc/free, another on new/delete.  Not all
compilers can (or want) to map new/delete to malloc/free so you also
could get increase memory fragmentation.  Overloading new/delete is a
nice idea, but again requires so may platform specific changes (because
nobody really supports this part of the standard in the same way).  Some
compilers don't even support block-level variable scope!

So, in summary, no STL in 3.5.  We just hope the situation improves in
the next 12 - 24 month (especially gcc 3.0), but initial 4.0 development
(if we can use the STL at all by then) might still be a pain...


     Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message